The risk for the compromise of data integrity increases over time, whether the data is being transmitted over a network or at rest in storage. This occurs because the data is exposed to network components (when in transit) or available for examination and modification (when stored). The risk of data being compromised may be tolerated to a certain extent, but unacceptable beyond a certain threshold or acceptable risk.
Protection of a computer or data network from undesired and unauthorized data disclosure, interception or alteration has been a perennial concern in the field of computer and network security. For example, firewall and anti-spyware software have been developed to address security concerns for computers and networks connected to the Internet and to protect them from possible cyber-attacks such as Trojan horse-type viruses or worms that may trigger undesired and unauthorized data disclosure by these computers and networks. However, for high security computer networks such as those used by government agencies and intelligence community and certain commercial applications, conventional network security devices such as firewalls may not provide sufficiently reliable protection from undesired data disclosure.
Alternative network security methods and devices based on unidirectional data transfer have been devised to address the network security concern. For example, U.S. Pat. No. 5,703,562 to Nilsen (“the '562 Patent”), which is hereby incorporated by reference in its entirety, provides an alternative way to address the network security concern. The '562 Patent discloses a method of transferring data from an unsecured computer to a secured computer over a one-way optical data link comprising an optical transmitter on the sending side and an optical receiver on the receiving side. By providing such an inherently unidirectional data link to a computer/data network to be protected, one can eliminate any possibility of unintended data leakage out of the computer/data network over the same link.
Any data link that strictly enforces the unidirectionality of data flow is called a one-way link or one-way data link. In other words, it is physically impossible to send information or data of any kind through a one-way data link in the reverse direction. A one-way data link may be hardware-based, software-based, or based on some combination of hardware and software.
One-way data transfer systems based on such one-way data links provide network security to data networks by isolating the networks from potential security breaches (i.e., undesired and unauthorized data flow out of the secure network) while still allowing them to import data from the external source in a controlled fashion. FIG. 1 schematically illustrates an example of one such one-way data transfer system 100. In the one-way data transfer system shown in FIG. 1, two computing platforms 101 and 102 (respectively, “the send platform” and “the receive platform”) are connected to the unsecured external network 104 (“the source network”) and the secure network 105 (“the destination network”), respectively. The send platform 101 is connected to the receive platform 102 by a one-way data link 103, which may be an optical link comprising, for example, a high-bandwidth optical fiber. This one-way optical data link 103 may be configured to operate as a unidirectional data gateway from the source network 104 to the secure destination network 105 by having its ends connected to an optical transmitter on the send platform and to an optical receiver on the receive platform.
A configuration such as the one shown in FIG. 1 physically enforces one-way data transfer at both ends of the optical fiber connecting the send platform 101 to the receive platform 102, thereby creating a truly unidirectional data transfer link between the source network 104 and the destination network 105. One-way data transfer systems based on a one-way data link are designed to transfer data or information in only one direction, making it physically impossible to transfer any kind of data, such as handshaking protocols, error messages, or busy signals, in the reverse direction. Such physically imposed unidirectionality in data flow cannot be hacked by a programmer, as is often done with firewalls, where unidirectional rules are software-protected (e.g., password authentication, etc.). Accordingly, the one-way data transfer system based on a one-way data link ensures that data residing on the isolated destination secure computer or network is maximally protected from any undesired and unauthorized disclosure. Alternatively, the source network is isolated from any malware contained in the destination network.
Software systems and applications, whether for direct use on a computer or embedded in other devices (e.g., firmware), often need to be installed and/or updated before initial use or periodically during the lifetime of such computer or device (i.e., to update to a new version or release). Such updates may add features, fix known problems and/or support the connection to or use of additional hardware and software components and systems. An initial software version or a software update (collectively a “payload” or “install payload”) may be delivered by the software or device manufacturer (or its agent) via recorded physical digital media (e.g., CDs, DVDs, USB drives, hard drives, etc.) or by making it available on an online server for delivery to or retrieval by an end user of the software or device. In some cases, e.g., a surgically-implanted device having internal updatable software/firmware, the payload may only be loaded into the device at a physician's office or other secure healthcare facility via a specialized programming apparatus.
There are cases in which the install payload could be compromised as the result of malicious modifications to code residing either on a physical media or on an online server. In other scenarios, regulatory and/or security requirements may forbid the introduction of physical media into a facility where the systems requiring the install payload is needed, e.g., because of the secure nature of such facility. For these scenarios, connecting to any external network may also be forbidden because of the danger posed by information exfiltration and exposure to malware as discussed above.
As described in U.S. Pat. No. 8,352,450, issued on Jan. 8, 2013 which is incorporated herein by reference in its entirety (“the '450 Patent”), files based on various conventional transport protocols may be transferred across a one-way data link under suitable arrangements. The following example illustrates transfer of files based on the Transmission Control Protocol (TCP) across a one-way data link. FIG. 2 is a functional block diagram that schematically illustrates implementation of a TCP-based secure file transfer across a single one-way data link in a one-way data transfer system 200.
Construction of the conventional TCP sockets requires bilateral communications since it requires an acknowledgement channel from the receive node to the send node. Accordingly, the conventional TCP/IP protocol cannot be implemented directly in a one-way data transfer system based on a one-way data link, since no bilateral “hand shaking” is allowed over the one-way link due to physical enforcement of unidirectionality of data flow. Instead, the one-way data transfer system 200 illustrated in FIG. 2 uses a TCP simulation application called TCP proxy, which is preferably a TCP/IP socket-based proxy software, but may also be hardware-based or based on a suitable combination of software and hardware, to simulate the TCP/IP protocol across the one-way data link 207.
In FIG. 2, a TCP server proxy 205 fully implements the TCP/IP protocol in its bilateral communications 203 with the upstream TCP file client 202 residing in a source platform 201. The TCP server proxy 205 may reside within the send node 204 as shown in FIG. 2, or alternatively, may be separate from but coupled to the send node 204. After the TCP server proxy 205 receives files from the TCP file client 202, the send node 204 sends the files through its interface 206 to the one-way data link 207. After the receive node 208 receives the files through its interface 209 from the one-way data link 207, the TCP client proxy 210 communicates under the full implementation of the TCP/IP protocol with a TCP file server 213 residing in a destination platform 212 and forwards the received files to the TCP file server 213. The TCP client proxy 210 may reside within the receive node 208 as shown in FIG. 2, or alternatively, may be separate from but coupled to the receive node 208.
In certain situations, it would be advantageous to use a one-way data link with an independent link layer protocol for one-way transfer so that non-routable point to point communications with a true IP protocol break can be enforced. With these properties, data packets or files cannot be accidentally routed in the network and other protocols (such as printer protocols, etc.) will not route across the one-way data link. An exemplary configuration enforcing such non-routable point to point communications with a true IP protocol break can be implemented in the one-way file transfer system 200 of FIG. 2. The TCP-based file transfer system 200 may be configured to prohibit transmission of IP information across the one-way data link 207. When the TCP server proxy 205 receives a file from the TCP file client 202, it removes the IP information normally carried in the file data packet headers under the TCP/IP protocol and replaces it with pre-assigned point-to-point channel numbers, so that no IP information is sent across the one-way data link 207. Instead, predetermined IP routes may be defined at the time of the configuration of the system 200 in the form of channel mapping tables residing in the TCP server proxy 205 associated with the send node 204 and the TCP client proxy 210 associated with the receive node 208. The send node 204 then sends the files with the pre-assigned channel numbers to the receive node 208 through its interface 206 across the one-way data link 207, which are received by the receive node 208 through its interface 209. Upon receipt of the files, the TCP client proxy 210 then maps the channel numbers from the received files to the corresponding predetermined IP address of a destination platform 212, to which the files are forwarded.
For the security of the overall one-way file transfer system 200, the IP address-to-channel number mapping table residing in the send node 204 may be different from the channel number-to-IP address mapping table residing in the receive node 208, and furthermore, neither table may be re-constructed on the basis of the other table. Neither table alone reveals the overall IP routing configuration from the source platform 201 to the destination platform 212. In this way, the IP information of the destination platform 212 may remain undisclosed to the sender at the source platform 201 and the security of the overall system 200 can be maintained.
Under the conventional TCP/IP protocol, the acknowledgement mechanism requiring bilateral communications may provide means for error detection. However, the one-way data link 207 forecloses such means. Instead, the one-way data transfer system 200 may assure file integrity by applying, for example, a hash algorithm such as MD5 to each file being transferred over the one-way data link 207. The send node 204 calculates an MD5 hash number for the file and sends the resulting hash number along with the file to the receive node 208 over the one-way data link 207. When the receive node 208 receives the file, it may re-calculate a hash number for the received file and compare the result with the hash number calculated by the send node 204. By comparing these results, the receive node 208 may be able to determine as to whether any error has occurred during the file transfer across the one-way data link.
As described in U.S. patent application Ser. No. 13/748,045, filed on Jan. 23, 2013, (“the '045 Application,” published as U.S. Patent Publication No. 2014/0020109 A1 on Jan. 16, 2014), which is incorporated herein by reference in its entirety, a manifest transfer engine 300 may operate as a file filtering device for securing one-way transfer of files.
As shown in FIG. 3A, the manifest transfer engine 300 comprises a send side 301, a receive side 303, and a one-way data link 302 enforcing unidirectional data flow from the send side 301 to the receive side 303. The send side 301 of the manifest transfer engine 300 is configured to receive a file manifest table 304 from the system administrator (e.g., administrator server 306 shown in FIG. 3A) and store it. The send side 301 is also configured to receive files 305 to be transferred across the one-way data link 302 from the user. The send side 301 of the manifest transfer engine 300 performs the file manifest filtering by comparing the received files 305 against the file manifest table 304 received from the administrator. Only upon validation based on the file manifest table 304 stored in the send side 301, the files 305 from the user are allowed to be transferred to the receive side 303 of the manifest transfer engine 300 via one-way data link 302.
The send side 301 of the manifest transfer engine 300 may comprise a file client configured to receive files 305 from the user and send them across the one-way data link 302 upon validation. Similarly, the receive side 303 of the manifest transfer engine 300 may comprise a file server configured to receive the files from the one-way data link 302 and forward the received file (i.e., as an authenticated file 307) to the intended recipient (e.g., a file server in the destination network). The send side 301 and the receive side 303 of the manifest transfer engine 300 may respectively comprise a TCP file client 202 and a TCP file server 213 shown in FIG. 2, which are respectively configured to transfer and receive files across one-way data link 207 via specifically configured TCP server and client proxies 205, 210. In this case, upon validation of the file 305 based on the file manifest table 304, the manifest transfer engine 300 may operate in the same or similar manner as the TCP-based file transfer system 200 of FIG. 2 to transfer the file across the one-way data link 302.
The file manifest table 304 may be created in the form of an ASCII-only text file containing hash numbers or other forms of identification corresponding to the files that are permitted to be transferred through one-way data link 302. For example, a manifest file may be assembled by the administrator based on the hash numbers provided by the user that correspond to the files that the user wishes to transfer across the network boundary via one-way data link 302. In another example, a manifest file may be assembled by the administrator based on the hash numbers of anti-virus and anti-malware updates and/or OS and software patches that are made publicly available from software companies.
The manifest transfer engine 300 may perform file manifest filtering as follows: The executable or non-executable file 305 received from the user by the send side 301 of the manifest transfer engine 300 is individually validated against the file manifest table 304 stored in the send side 301. In one or more embodiments, the send side 301 calculates a hash number for the received file 305 and compares it with the registered hash numbers listed on the file manifest table 304. If there is a match, the file 305 is validated and the send side 301 allows it to be transferred to the receive side 303 via one-way data link 302. On the other hand, if no match is found, the file 305 is denied transfer across one-way data link 302 and may be quarantined or deleted by the send side 301 or by the administrator. The incident of finding no match may be logged.
FIG. 3B illustrates an alternative exemplary embodiment of the manifest transfer engine 310. The send side 311 of the manifest transfer engine 310 is configured to receive a file 315 from the user and send it to the receive side 313 via a one-way data link 312. Unlike the manifest transfer engine 300 of FIG. 3A in which the send side 301 is configured to receive and store a file manifest table 304 from admin server 306 and perform the file manifest filtering, in the manifest transfer engine 310 of FIG. 3B, the receive side 313 is configured to receive and store a file manifest table 314 from admin server 316 and to perform the file manifest filtering by comparing the file 315 received from the one-way data link 312 against the file manifest table 314. As a further variation, the file manifest table 314 may also be provided via the one-way data link 312 instead of via a separate connection. In this case, the file manifest table 314 must be properly tagged to allow the receive side 313 to distinguish it from file 315. Only upon validation based on the file manifest table 314 stored in the receive side 313, the file 315 from the user is allowed to be released and forwarded as an authenticated file 317 to the destination. If the file fails validation based on the file manifest table 314, the receive side 313 does not release the file and may delete or quarantine the file. Except for the above described differences, other aspects of the file manifest filtering by the manifest transfer engine 310 of FIG. 3B may be same or substantially similar to those of the manifest transfer engine 300 of FIG. 3A.
The manifest transfer engines 300, 310 disclosed in the '045 Application provide a way to authenticate files being transferred from a source to a destination. However, the prior art does not address how to deal with information files which have become stale—i.e., unchanged for a period of time after creation of the file and associated manifest entry, and possibly altered.
The present invention provides a system and method for data transfer/data assurance which overcome the problems with the prior art. Other advantages of the present invention will become apparent from the following description.